Datadog でログを自在に操る！パイプラインとプロセッサーの活用法

Datadog でログを自在に操る！パイプラインとプロセッサーの活用法

#Datadog
Shiina

Shiina

facebook logohatena logotwitter logo
Clock Icon2024.12.02

こんにちは。テクニカルサポートチームのShiinaです。

はじめに

Datadog のログ管理機能はコスト効率よく、制限なしにすべてのログを収集、処理、アーカイブ、検索、監視することが可能です。
しかしながらログの形式は多種多様であり、すべてのログ形式を処理しやすいように変換してくれるものではありません。
ログメッセージの重要度を示すステータスが一致しなかったり、メッセージ自体がパースされない場合もあります。
今回は上記ケースの例をもとに、パイプラインとプロセッサーの活用方法を紹介します。

パイプラインとは

広範囲の形式から取得したログを Datadog で一般的に扱えるような形式に変換する機能のことです。
JSON 形式のログは自動でパースしてくれますが、それ以外の形式ではパイプラインを利用する必要があります。
Datadog ではインテグレーションごとに専用のパイプラインライブラリが用意されています。
ログの収集設定を行うコンフィグレーションファイル(conf.yaml)で正しいログソースを設定することで、パイプラインライブラリーを利用してログの形式変換を自動でしてくれます。
例えば、source:nginx とした場合、nginx のパイプラインが利用されます。
nginx

プロセッサーとは

ログを加工・変換するためのツールで、パイプライン内で順次実行されます。
そのため、プロセッサーの順序には注意が必要です。
主な機能として、パース処理、属性の追加/削除、文字列の置換、ルックアップテーブルの適用などがあります。
これらのプロセッサーを組み合わせることで、生ログから構造化されたデータへの変換や、必要な情報の抽出が可能になります。

Grok パーサーとは

Datadog で利用される半構造化されたメッセージをパースする専用プロセッサーです。
メッセージから属性を抽出することができます。
パース規則は、正規表現よりも簡単な %{MATCHER:EXTRACT:FILTER} 構文を使用して記述します。

  • ログメッセージ
Welcome to Production Web-Server - Logged in as admin
  • パース構文
Rule Welcome to %{word:env} %{data:server} - Logged in as %{word:user}
  • 結果
    次のようなログ属性が生成されます。
{
  "server": "Web-Server",
  "env": "Production",
  "user": "admin"
}

ログ属性は JSON のキーにように動作するため、キーと値を指定したログ検索を行うことが可能になります。

ログメッセージのステータス

Datadog はログメッセージの重大度によってステータスをマッピングします。
Log Explorer ではステータスに応じてログメッセージの背景色が変わります。
また、ログメッセージのステータスに応じた Standard Attributes の Status によるフィルタ検索も可能となります。

status

ログソースごとに定められている重要度を示す属性の値となっている文字列によってログのステータスが決まります。
上記はログステータスリマッパーを利用することで任意の属性に割り当てることができます。

文字列 マッピング
emerg*, f* emerg (0)
a* alert (1)
c* critical (2)
err* error (3)
w* warning (4)
n* notice (5)
i* info (6)
d*, t*, v*, trace*, verbose* debug (7)
o*, s*, OK, Success OK
その他 info (6)

整数値を受け取った場合、()の値に示す、Syslog の重大度標準にマップされます。
例として、3の場合は error となります。

日本語版 Windows イベントログのステータスの例

日本語にローカライズされた Windows ではイベントログの重大度表記も日本語となります。
重大度を示す属性である level の値が "エラー" という文字列となっており、マッピング表では "その他" と分類されます。
その結果、ステータスは info と割り当てされてしまいます。
info で統一されてしまうと可視性が低下し、Status によるフィルタ検索が行えません。
パイプライン設定を行い、正しいステータスに割り当てを行ってみます。

パイプライン設定前のログ表記

ログ収集設定

Windows のイベントログを収集する Datadog エージェントのコンフィギュレーションファイルのサンプルは次のとおりです。

win32_event_log.d/conf.yaml
logs:
  - type: windows_event
    channel_path: Application
    source: windows.events
    service: web-server

  - type: windows_event
    channel_path: System
    source: windows.events
    service: web-server

  - type: windows_event
    channel_path: Security
    source: windows.events
    service: web-server

ファイル修正後、Datadog エージェントを再起動して設定を反映させます。

パイプライン設定

Logs から Pipelines を選択します。
pipelinemenu

Pipelines 一覧より Windows Events にカーソルを移動し、「Clone」をクリックします。
※source: windows.eventsと設定することで Windows Events インテグレーションが有効化され、自動でパイプラインが登録されます。

クローン

Are you sure? と聞かれるので「Clone」をクリックします。
元のパイプラインが無効化され、クローンされたパイプラインが追加されます。

クローン後

プロセッサー設定

カテゴリープロセッサーとステータスリマッパーをパイプラインに追加します。
Pipelines 一覧より Clone した Windows Events のパイプラインを選択します。
選択するとパイプラインに登録されているプロセッサーの一覧が表示されます。

①カテゴリープロセッサー追加
「Add Processor」をクリックします。

プロセッサー追加

次のように入力を行い、「Create」をクリックします。

  • Select the processor type
    Category Processor
  • Name the processor
    JapaneseWindowsEventlog-CategoryRemapper
  • Set target category attribute
    eventlog_level
  • Populate category
    All events that match と Appear under the value name に対して以下の値を入力し、「Add」をクリックします。
    重大度ごとにそれぞれ設定を行います。
All events that match Appear under the value name
@level:重大 Emergency
@level:エラー Error
@level:警告 Warning
@level:情報 Info

カテゴリプロセッサー設定

②ステータスリマッパーの追加
「Add Processor」をクリックします。
次のように入力を行い、「Create」をクリックします。

  • Select the processor type
    Status Remapper
  • Name the processor
    JapaneseWindowsEventlog-StatusRemapper
  • Set status attribute(s)
    eventlog_level

ステータスリマッパー設定

設定後、プロセッサーの一覧が次のように表示されていれば OK です。

パイプライン設定後

パイプライン設定後のログメッセージ

情報、警告、エラーのイベントログを擬似的に出力し、Log Explorer でログを見てみます。
ステータスが割り当てされていることが確認できます。
パイプライン設定後のログ表記

ログメッセージをクリックし、メッセージの属性も見てみます。
カテゴリープロセッサーにより level:エラー の属性から eventlog_level:Error という新しい属性が付与されています。
さらにステータスリマッパーにより重要度の属性を eventlog_level と割り当てたため、マッピングされるメッセージのステータスは Error になりました。
windowsログ属性説明

RDS for MySQL のエラーログ（CloudWatch Logs）の例

CloudWatch Logs に出力される RDS for MySQL のエラーログは source:rds が設定されます。
上記ログソースに対するパイプラインは用意されていません。
メッセージのパースが行われないため、生ログメッセージがそのまま出力されています。
また、重要度を示す属性がなく、ステータスは info と割り当てされてしまいます。
パイプライン設定を行い、パースおよびステータスの割り当てを行ってみます。
rdsパイプライン設定ログ

ログ収集設定

はじめに RDS の設定でログのエクスポートでエラーログタイプを選択し、CloudWatch Logs にログを発行させます。
RDS-ap-northeast-1-11-28-2024_03_36_PM

次に Datadog Forwarder Lambda 関数を利用して CloudWatch Logs のログを収集します。
Lambda サブスクリプションフィルターを作成し、Datadog Forwarder Lambda 関数にサブスクライブさせます。
CloudWatch-ap-northeast-1-11-29-2024_01_39_PM

パイプライン設定

Logs から Pipelines を選択します。
pipelinemenu

Pipelines 一覧より「Add a new pipeline」をクリックします。
パイプラインadd

次のように入力を行い、「Create」をクリックします。

  • Filter
    source:rds
  • Name
    RDS for MySQL Error Log
    rds pipeline

プロセッサー設定

Grok パーサー、ステータスリマッパー、メッセージリマッパーをパイプラインに追加します。
Pipelines 一覧より追加した RDS for MySQL Error Log のパイプラインを選択します。

①Grok パーサー追加
「Add Processor」をクリックします。
addプロセッサー

次のように入力を行い、「Create」をクリックします。

  • Select the processor type
    Grok Parser
  • Name
    RDS for MySQL Error Log-Grok Parser
  • log samples
    2024-11-27T06:59:09.482526Z 5 [Note] [MY-010051] [Server] Event Scheduler: scheduler thread started with id 5 (event_scheduler.cc:564)
  • Define parsing rules
    Rule %{date("yyyy-MM-dd'T'HH:mm:ss.SSSSSS'Z'"):timestamp} %{number:thread} \[%{word:label}\] \[%{data:err_code}\] \[%{word:subsystem}\] %{data:msg}

エラーログ出力形式[1]および MySQL Server ログのコアエラーイベントフィールド[2]を参考に、パースを行います。
rdsgrokparser

②ステータスリマッパーの追加
「Add Processor」をクリックします。
次のように入力を行い、「Create」をクリックします。

  • Select the processor type
    Status Remapper
  • Name the processor
    RDS for MySQL Error Log-StatusRemapper
  • Set status attribute(s)
    label
    rdsstatusremapper

③メッセージリマッパーの追加
「Add Processor」をクリックします。
次のように入力を行い、「Create」をクリックします。

  • Select the processor type
    Message Remapper
  • Name the processor
    RDS for MySQL Error Log-MessageRemapper
  • Set status attribute(s)
    msg
    rdsmessageremapper

設定後、プロセッサーの一覧が次のように表示されていれば OK です。
rdsパイプライン設定後

パイプライン設定後のログメッセージ

Log Explorer でログを見てみます。
ステータスが割り当てされていることが確認できます。
Log Explorer では属性をカラムに追加することができるため、@err_code @subsystem も追加してみました。
CONTEXT 列にはメッセージ内容のみ表示されて、だいぶスッキリしました。
rdsメッセージパイプライン追加後

ログメッセージをクリックし、メッセージの属性も見てみます。
Grok パーサーにより次の属性が追加されました。
・timestamp
・thread
・label
・err_code
・subsystem
・msg
ステータスリマッパーにより重要度の属性を label と割り当てたため、マッピングされるメッセージのステータスは Warning になりました。
メッセージリマッパーでメッセージ属性に msg を割り当てたため、 CONTEXT 列に表示されました。
rdsメッセージ属性説明

まとめ

Datadog のログ管理機能では、パイプラインとプロセッサーを活用してログの形式変換や処理が可能です。
Grok パーサーを用いて半構造化データを解析し、ステータスリマッパーでステータス属性をカスタマイズできます。
日本語版 Windows イベントログや CloudWatch Logs に出力される RDS for MySQL のエラーログにも柔軟に対応が可能です。
ログの検索性と可視性が向上しますので、ぜひパイプラインを活用してみてください。

本記事が誰かのお役に立てれば幸いです。

参考

https://docs.datadoghq.com/ja/logs/log_configuration/pipelines/?tab=source
https://docs.datadoghq.com/ja/logs/log_configuration/processors/?tab=ui
https://docs.datadoghq.com/ja/logs/log_configuration/parsing/?tab=マッチャー
https://docs.datadoghq.com/ja/integrations/win32_event_log/?tab=ログ

脚注

  1. https://dev.mysql.com/doc/refman/8.0/ja/error-log-format.html ↩︎

  2. https://dev.mysql.com/doc/refman/8.0/ja/error-log-event-fields.html#error-log-event-core-fields ↩︎

Share this article

facebook logohatena logotwitter logo

関連記事

Datadog 認定試験「Log Management Fundamentals」を受けてみた

Datadog 認定試験「Log Management Fundamentals」を受けてみた

User avatar
Shiina
2024.11.26
Datadog で AWS PrivateLink を使ったプライベートネットワーク接続をやってみた

Datadog で AWS PrivateLink を使ったプライベートネットワーク接続をやってみた

User avatar
Shiina
2024.10.30
Datadog 認定試験「Datadog Fundamentals」を受けてみた

Datadog 認定試験「Datadog Fundamentals」を受けてみた

User avatar
Shiina
2024.10.16
CloudWatch GetMetricData でリクエストされているメトリクス内訳を CloudTrailログから把握する

CloudWatch GetMetricData でリクエストされているメトリクス内訳を CloudTrailログから把握する

User avatar
川原征大
2024.09.17
Classmethod's white logo
Facebook's logo
X's logo
YouTube's logo

© Classmethod, Inc. All rights reserved.